Organizations and businesses depend on software deployed throughout their computing infrastructures to perform tasks relevant to their respective fields. As these entities begin using more enterprise software solutions, enterprise-wide software support becomes a necessary corollary to the software itself, as technical issues and performance errors may inevitably arise during the software's normal operations. For example, a customer may experience technical errors affecting the operations of the current software. In some support solutions, the customer may be required to submit or report the error through a manual process. Upon receiving the error report or notice, the support provider may manually analyze the error, diagnose the problem, and determine the proper solution. Once found, the support provider may relay the solution to the customer, who may then attempt to implement the steps of the provided solution. In some of these situations, such as those involving a customer support phone hotline, the customer generally needs a rudimentary level of knowledge regarding the software to ensure that the dialog between the technical consultant and the customer is clear enough to allow for a successful resolution to the issue.
Conventionally, support technicians and users need access to a customer's system in order to debug and otherwise troubleshoot the software. Sometimes, technicians may work with a copy of the production work environment, but even then it is not always possible to recreate the error.
Analyzing errors that occur within client systems can be a labor intensive endeavor. There are many types of errors that may occur within a system and each may require a different level of debugging. Three types of errors typically require some amount of code debugging. In order of severity, they are: program termination errors, business process errors, and simple miscalculations. Program termination errors are the most severe and result in the termination of the execution of a client's backend system. Debugging program termination errors generally requires recreation or simulation of the error and its accompanying data dump in a support system because it is typically undesirable for testing to be performed in a production environment. Support technicians may need to debug the logic contained in all levels, even down to the implementation details of certain business objects.
Business process errors, as the name implies, halt the execution of a business process, even though the overall system may continue to run. For example, a system may prevent the saving of a PurchaseOrder business object order because of a technical error (e.g., inappropriate divide by zero) or a business logic error. A business logic error may result from applying an incorrect business rule. For example, there may be a legal requirement applicable to business done in Italy requiring that certain tax documents be created before closing a certain business order object. If the requirement were applied in a Spanish context, the system may prevent a user from closing the PurchaseOrder business object instance for failing to create an irrelevant document that the wrongly configured system required. This type of incident may also require debugging the logic of a business object. The third type of incident is a simple miscalculation. With this category of error, the system may be technically sound, but errors in logic prevent the system from producing correct results. For example, a pricing function, which should appropriately apply two rebates, may apply only the first, resulting in the wrong price for a good.